TypeScript Master Data Management: คู่มือการนำประเภทข้อมูลอ้างอิงไปใช้งาน

ในโลกที่ซับซ้อนของการพัฒนาซอฟต์แวร์ระดับองค์กร ข้อมูลคือหัวใจสำคัญของทุกแอปพลิเคชัน วิธีการที่เราจัดการ จัดเก็บ และใช้ข้อมูลนี้ส่งผลโดยตรงต่อความแข็งแกร่ง ความสามารถในการบำรุงรักษา และความสามารถในการปรับขนาดของระบบของเรา ข้อมูลส่วนสำคัญหนึ่งในนี้คือ Master Data—เอนทิตีหลักที่ไม่ใช่ธุรกรรมของธุรกิจ ภายในขอบเขตนี้ Reference Data โดดเด่นในฐานะเสาหลัก บทความนี้ให้คำแนะนำที่ครอบคลุมสำหรับนักพัฒนาและสถาปนิกในการนำประเภทข้อมูลอ้างอิงไปใช้งานและจัดการโดยใช้ TypeScript ซึ่งจะเปลี่ยนแหล่งที่มาทั่วไปของข้อผิดพลาดและความไม่สอดคล้องกันให้เป็นฐานที่มั่นของความสมบูรณ์ที่ปลอดภัยทางประเภท

เหตุใดการจัดการข้อมูลอ้างอิงจึงมีความสำคัญในแอปพลิเคชันสมัยใหม่

ก่อนที่จะลงลึกไปในโค้ด เรามาทำความเข้าใจแนวคิดหลักของเราให้ชัดเจนก่อน

Master Data Management (MDM) คือระเบียบวินัยที่ใช้เทคโนโลยี ซึ่งธุรกิจและไอทีทำงานร่วมกันเพื่อให้มั่นใจถึงความสม่ำเสมอ ความถูกต้อง การดูแลจัดการ ความสอดคล้องทางความหมาย และความรับผิดชอบของสินทรัพย์ข้อมูลหลักที่ใช้ร่วมกันอย่างเป็นทางการขององค์กร ข้อมูลหลักแสดงถึง "คำนาม" ของธุรกิจ เช่น ลูกค้า ผลิตภัณฑ์ พนักงาน และสถานที่

Reference Data คือข้อมูลหลักประเภทเฉพาะที่ใช้ในการจำแนกหรือจัดหมวดหมู่ข้อมูลอื่น ๆ โดยทั่วไปแล้วข้อมูลนี้จะคงที่หรือไม่เปลี่ยนแปลงช้ามากเมื่อเวลาผ่านไป ลองคิดว่ามันเป็นชุดของค่าที่กำหนดไว้ล่วงหน้าที่ฟิลด์ใดฟิลด์หนึ่งสามารถใช้ได้ ตัวอย่างทั่วไปจากทั่วโลกได้แก่:

• รายการประเทศ (เช่น สหรัฐอเมริกา, เยอรมนี, ญี่ปุ่น)
• รหัสสกุลเงิน (USD, EUR, JPY)
• สถานะคำสั่งซื้อ (รอดำเนินการ, กำลังประมวลผล, จัดส่งแล้ว, จัดส่งถึงแล้ว, ยกเลิกแล้ว)
• บทบาทผู้ใช้ (ผู้ดูแลระบบ, ผู้แก้ไข, ผู้ดู)
• หมวดหมู่ผลิตภัณฑ์ (อิเล็กทรอนิกส์, เครื่องแต่งกาย, หนังสือ)

ความท้าทายของข้อมูลอ้างอิงไม่ใช่ความซับซ้อน แต่เป็นการแพร่หลาย มันปรากฏอยู่ทุกที่: ในฐานข้อมูล, เพย์โหลด API, ตรรกะทางธุรกิจ และส่วนต่อประสานผู้ใช้ เมื่อจัดการได้ไม่ดี จะนำไปสู่ปัญหาที่ตามมามากมาย: ความไม่สอดคล้องของข้อมูล, ข้อผิดพลาดรันไทม์ และ codebase ที่ยากต่อการบำรุงรักษาและปรับปรุง นี่คือจุดที่ TypeScript ด้วยระบบการพิมพ์แบบคงที่อันทรงพลัง กลายเป็นเครื่องมือที่ขาดไม่ได้สำหรับการบังคับใช้การกำกับดูแลข้อมูลตั้งแต่ขั้นตอนการพัฒนา

ปัญหาหลัก: อันตรายของ "Magic Strings"

เรามาแสดงให้เห็นปัญหาด้วยสถานการณ์ทั่วไป: แพลตฟอร์มอีคอมเมิร์ซระหว่างประเทศ ระบบจำเป็นต้องติดตามสถานะของคำสั่งซื้อ การนำไปใช้งานแบบง่ายๆ อาจเกี่ยวข้องกับการใช้สตริงดิบโดยตรงในโค้ด:

            
function processOrder(orderId: number, newStatus: string) {
  if (newStatus === 'shipped') {
    // Logic for shipping
    console.log(`Order ${orderId} has been shipped.`);
  } else if (newStatus === 'delivered') {
    // Logic for delivery confirmation
    console.log(`Order ${orderId} confirmed as delivered.`);
  } else if (newStatus === 'pending') {
    // ...and so on
  }
}

// Somewhere else in the application...
processOrder(12345, 'Shipped'); // Uh oh, a typo!

            

              
                Copy
              
            
          

วิธีการนี้ ซึ่งอาศัยสิ่งที่มักเรียกว่า "magic strings" เต็มไปด้วยอันตราย:

• ข้อผิดพลาดจากการพิมพ์: ดังที่เห็นข้างต้น `shipped` เทียบกับ `Shipped` อาจทำให้เกิดข้อผิดพลาดเล็กน้อยที่ตรวจจับได้ยาก คอมไพเลอร์ไม่ให้ความช่วยเหลือ
• ขาดการค้นพบ: นักพัฒนาคนใหม่ไม่มีวิธีง่ายๆ ที่จะรู้ว่าสถานะที่ถูกต้องคืออะไร พวกเขาต้องค้นหา codebase ทั้งหมดเพื่อค้นหาค่าสตริงที่เป็นไปได้ทั้งหมด
• ฝันร้ายในการบำรุงรักษา: จะเกิดอะไรขึ้นถ้าธุรกิจตัดสินใจเปลี่ยน 'shipped' เป็น 'dispatched'? คุณจะต้องดำเนินการค้นหาและแทนที่ทั่วทั้งโปรเจกต์อย่างเสี่ยง โดยหวังว่าจะไม่พลาดอินสแตนซ์ใดๆ หรือเปลี่ยนสิ่งที่ไม่เกี่ยวข้องโดยไม่ตั้งใจ
• ไม่มีแหล่งข้อมูลเดียวที่เชื่อถือได้: ค่าที่ถูกต้องกระจัดกระจายอยู่ทั่วแอปพลิเคชัน ซึ่งนำไปสู่ความไม่สอดคล้องกันที่อาจเกิดขึ้นระหว่างส่วนหน้า ส่วนหลัง และฐานข้อมูล

เป้าหมายของเราคือการกำจัดปัญหาเหล่านี้โดยการสร้างแหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียวสำหรับข้อมูลอ้างอิงของเรา และใช้ประโยชน์จากระบบประเภทของ TypeScript เพื่อบังคับใช้การใช้งานที่ถูกต้องในทุกที่

รูปแบบพื้นฐานของ TypeScript สำหรับข้อมูลอ้างอิง

TypeScript มีรูปแบบที่ยอดเยี่ยมหลายอย่างสำหรับการจัดการข้อมูลอ้างอิง แต่ละรูปแบบมีข้อดีข้อเสียที่แตกต่างกันไป ลองสำรวจรูปแบบที่พบบ่อยที่สุด ตั้งแต่แบบคลาสสิกไปจนถึงแนวทางปฏิบัติที่ดีที่สุดสมัยใหม่

แนวทางที่ 1: `enum` แบบคลาสสิก

สำหรับนักพัฒนาหลายคนที่มาจากภาษาอย่าง Java หรือ C# `enum` เป็นเครื่องมือที่คุ้นเคยที่สุดสำหรับงานนี้ ช่วยให้คุณสามารถกำหนดชุดของค่าคงที่ที่มีชื่อได้

            
export enum OrderStatus {
  Pending = 'PENDING',
  Processing = 'PROCESSING',
  Shipped = 'SHIPPED',
  Delivered = 'DELIVERED',
  Cancelled = 'CANCELLED',
}

function processOrder(orderId: number, newStatus: OrderStatus) {
  if (newStatus === OrderStatus.Shipped) {
    console.log(`Order ${orderId} has been shipped.`);
  }
}

processOrder(123, OrderStatus.Shipped); // Correct and type-safe
// processOrder(123, 'SHIPPED'); // Compile-time error! Great!

            

              
                Copy
              
            
          

ข้อดี:

• ความตั้งใจที่ชัดเจน: ระบุอย่างชัดเจนว่าคุณกำลังกำหนดชุดของค่าคงที่ที่เกี่ยวข้อง ชื่อ `OrderStatus` อธิบายได้ดีมาก
• การพิมพ์แบบระบุชื่อ: `OrderStatus.Shipped` ไม่ใช่แค่สตริง 'SHIPPED' แต่เป็นประเภท `OrderStatus` ซึ่งสามารถให้การตรวจสอบประเภทที่แข็งแกร่งขึ้นในบางสถานการณ์
• ความสามารถในการอ่าน: `OrderStatus.Shipped` มักถูกพิจารณาว่าอ่านง่ายกว่าสตริงดิบ

ข้อเสีย:

• JavaScript Footprint: TypeScript enums ไม่ใช่แค่โครงสร้างที่คอมไพล์ไทม์เท่านั้น แต่ยังสร้างออบเจกต์ JavaScript (Immediately Invoked Function Expression หรือ IIFE) ในผลลัพธ์ที่คอมไพล์ ซึ่งเพิ่มขนาดบันเดิลของคุณ
• ความซับซ้อนกับ Numeric Enums: แม้ว่าเราจะใช้สตริง enums ที่นี่ (ซึ่งเป็นแนวทางปฏิบัติที่แนะนำ) แต่ numeric enums เริ่มต้นใน TypeScript อาจมีพฤติกรรมการแมปย้อนกลับที่สับสน
• ความยืดหยุ่นน้อยลง: การอนุพันธ์ประเภทสหภาพจาก enums หรือการใช้สำหรับโครงสร้างข้อมูลที่ซับซ้อนขึ้นทำได้ยากขึ้นโดยไม่ต้องทำงานเพิ่มเติม

แนวทางที่ 2: Lightweight String Literal Unions

แนวทางที่เบากว่าและเป็นระดับประเภทล้วนๆ คือการใช้สหภาพของสตริงลิเทอรัล รูปแบบนี้กำหนดประเภทที่สามารถเป็นหนึ่งในชุดของสตริงที่เฉพาะเจาะจงเท่านั้น

            
export type OrderStatus = 
  | 'PENDING'
  | 'PROCESSING'
  | 'SHIPPED'
  | 'DELIVERED'
  | 'CANCELLED';

function processOrder(orderId: number, newStatus: OrderStatus) {
  if (newStatus === 'SHIPPED') {
    console.log(`Order ${orderId} has been shipped.`);
  }
}

processOrder(123, 'SHIPPED'); // Correct and type-safe
// processOrder(123, 'shipped'); // Compile-time error! Awesome!

            

              
                Copy
              
            
          

ข้อดี:

• ไม่มี JavaScript Footprint: การกำหนด `type` จะถูกลบออกทั้งหมดระหว่างการคอมไพล์ โดยมีอยู่เฉพาะสำหรับคอมไพเลอร์ TypeScript เท่านั้น ซึ่งส่งผลให้ JavaScript สะอาดขึ้นและมีขนาดเล็กลง
• ความเรียบง่าย: ไวยากรณ์ตรงไปตรงมาและเข้าใจง่าย
• Autocompletion ที่ยอดเยี่ยม: โปรแกรมแก้ไขโค้ดให้ Autocompletion ที่ยอดเยี่ยมสำหรับตัวแปรของประเภทนี้

ข้อเสีย:

• ไม่มีสิ่งประดิษฐ์รันไทม์: นี่เป็นทั้งข้อดีและข้อเสีย เนื่องจากเป็นเพียงประเภท คุณจึงไม่สามารถวนซ้ำค่าที่เป็นไปได้ในรันไทม์ (เช่น เพื่อเติมเมนูแบบเลื่อนลง) คุณจะต้องกำหนดอาร์เรย์ของค่าคงที่แยกต่างหาก ซึ่งนำไปสู่การซ้ำซ้อนของข้อมูล

            
// Duplication of values
export type OrderStatus = 'PENDING' | 'PROCESSING' | 'SHIPPED';

export const ALL_ORDER_STATUSES = ['PENDING', 'PROCESSING', 'SHIPPED'];

            

              
                Copy
              
            
          

การซ้ำซ้อนนี้เป็นการละเมิดหลักการ Don't Repeat Yourself (DRY) อย่างชัดเจน และเป็นแหล่งที่มาของข้อผิดพลาดที่อาจเกิดขึ้นหากประเภทและอาร์เรย์ไม่ตรงกัน ซึ่งนำเราไปสู่แนวทางที่ทันสมัยและเป็นที่ต้องการ

แนวทางที่ 3: พลังของ `const` Assertion (มาตรฐานทองคำ)

การยืนยัน `as const` ซึ่งเปิดตัวใน TypeScript 3.4 ให้โซลูชันที่สมบูรณ์แบบ มันรวมสิ่งที่ดีที่สุดของทั้งสองโลกเข้าด้วยกัน: แหล่งข้อมูลเดียวที่เชื่อถือได้ซึ่งมีอยู่ในรันไทม์และสหภาพที่ได้รับประเภทอย่างสมบูรณ์แบบซึ่งมีอยู่ในคอมไพล์ไทม์

นี่คือรูปแบบ:

            
// 1. Define the runtime data with 'as const'
export const ORDER_STATUSES = [
  'PENDING',
  'PROCESSING',
  'SHIPPED',
  'DELIVERED',
  'CANCELLED',
] as const;

// 2. Derive the type from the runtime data
export type OrderStatus = typeof ORDER_STATUSES[number];
//   ^? type OrderStatus = "PENDING" | "PROCESSING" | "SHIPPED" | "DELIVERED" | "CANCELLED"

// 3. Use it in your functions
function processOrder(orderId: number, newStatus: OrderStatus) {
  if (newStatus === 'SHIPPED') {
    console.log(`Order ${orderId} has been shipped.`);
  }
}

// 4. Use it at runtime AND compile time
processOrder(123, 'SHIPPED'); // Type-safe!

// And you can easily iterate over it for UIs!
function getStatusOptions() {
  return ORDER_STATUSES.map(status => ({ value: status, label: status.toLowerCase() }));
}

            

              
                Copy
              
            
          

มาดูกันว่าทำไมสิ่งนี้ถึงมีพลังมาก:

• `as const` บอกให้ TypeScript อนุมานประเภทที่เฉพาะเจาะจงที่สุดเท่าที่จะเป็นไปได้ แทนที่จะเป็น `string[]` จะอนุมานประเภทเป็น `readonly ['PENDING', 'PROCESSING', ...]` ตัวดัดแปลง `readonly` ป้องกันการแก้ไขอาร์เรย์โดยไม่ตั้งใจ
• `typeof ORDER_STATUSES[number]` คือเวทมนตร์ที่อนุมานประเภท มันบอกว่า "ให้ฉันประเภทขององค์ประกอบภายในอาร์เรย์ `ORDER_STATUSES`" TypeScript ฉลาดพอที่จะเห็นสตริงลิเทอรัลที่เฉพาะเจาะจงและสร้างประเภทสหภาพจากพวกมัน
• แหล่งข้อมูลเดียวที่เชื่อถือได้ (SSOT): อาร์เรย์ `ORDER_STATUSES` เป็นที่เดียวและที่เดียวที่ค่าเหล่านี้ถูกกำหนด ประเภทจะถูกอนุมานโดยอัตโนมัติจากมัน หากคุณเพิ่มสถานะใหม่ลงในอาร์เรย์ ประเภท `OrderStatus` จะอัปเดตโดยอัตโนมัติ ซึ่งจะช่วยขจัดความเป็นไปได้ที่ประเภทและค่ารันไทม์จะไม่ตรงกัน

รูปแบบนี้เป็นวิธีการจัดการข้อมูลอ้างอิงที่เรียบง่ายใน TypeScript ที่ทันสมัย เป็นไปตามหลักการ และแข็งแกร่ง

การนำไปใช้งานขั้นสูง: การจัดโครงสร้างข้อมูลอ้างอิงที่ซับซ้อน

ข้อมูลอ้างอิงมักจะซับซ้อนกว่ารายการสตริงธรรมดา ลองพิจารณาการจัดการรายการประเทศสำหรับแบบฟอร์มการจัดส่ง แต่ละประเทศมีชื่อ รหัส ISO สองตัวอักษร และรหัสการโทร รูปแบบ `as const` สามารถปรับขนาดได้อย่างสวยงามสำหรับสิ่งนี้

การกำหนดและจัดเก็บคอลเลกชันข้อมูล

ขั้นแรก เราสร้างแหล่งข้อมูลเดียวที่เชื่อถือได้ของเรา: อาร์เรย์ของออบเจกต์ เราใช้ `as const` กับมันเพื่อให้โครงสร้างทั้งหมดเป็น `readonly` อย่างลึกซึ้ง และเพื่ออนุญาตให้มีการอนุมานประเภทที่แม่นยำ

            
export const COUNTRIES = [
  {
    code: 'US',
    name: 'United States of America',
    dial: '+1',
    continent: 'North America',
  },
  {
    code: 'DE',
    name: 'Germany',
    dial: '+49',
    continent: 'Europe',
  },
  {
    code: 'IN',
    name: 'India',
    dial: '+91',
    continent: 'Asia',
  },
  {
    code: 'BR',
    name: 'Brazil',
    dial: '+55',
    continent: 'South America',
  },
] as const;

            

              
                Copy
              
            
          

การอนุพันธ์ประเภทที่แม่นยำจากคอลเลกชัน

ตอนนี้ เราสามารถอนุมานประเภทที่มีประโยชน์และเฉพาะเจาะจงสูงได้โดยตรงจากโครงสร้างข้อมูลนี้

            
// Derive the type for a single country object
export type Country = typeof COUNTRIES[number];
/*
  ^? type Country = {
      readonly code: "US";
      readonly name: "United States of America";
      readonly dial: "+1";
      readonly continent: "North America";
  } | {
      readonly code: "DE";
      ...
  }
*/

// Derive a union type of all valid country codes
export type CountryCode = Country['code']; // or `typeof COUNTRIES[number]['code']`
//   ^? type CountryCode = "US" | "DE" | "IN" | "BR"

// Derive a union type of all continents
export type Continent = Country['continent'];
//   ^? type Continent = "North America" | "Europe" | "Asia" | "South America"

            

              
                Copy
              
            
          

นี่เป็นสิ่งที่มีพลังอย่างไม่น่าเชื่อ โดยไม่ต้องเขียนการกำหนดประเภทที่ซ้ำซ้อนแม้แต่บรรทัดเดียว เราได้สร้าง:

1. ประเภท `Country` ที่แสดงถึงรูปร่างของออบเจกต์ประเทศ
2. ประเภท `CountryCode` ที่รับรองว่าตัวแปรหรือพารามิเตอร์ฟังก์ชันใดๆ สามารถเป็นได้เพียงหนึ่งในรหัสประเทศที่ถูกต้องและมีอยู่เท่านั้น
3. ประเภท `Continent` สำหรับจัดหมวดหมู่ประเทศ

หากคุณเพิ่มประเทศใหม่ลงในอาร์เรย์ `COUNTRIES` ประเภททั้งหมดเหล่านี้จะอัปเดตโดยอัตโนมัติ นี่คือความสมบูรณ์ของข้อมูลที่บังคับใช้โดยคอมไพเลอร์

การสร้างบริการข้อมูลอ้างอิงแบบรวมศูนย์

เมื่อแอปพลิเคชันเติบโตขึ้น แนวทางปฏิบัติที่ดีที่สุดคือการรวมศูนย์การเข้าถึงข้อมูลอ้างอิงนี้ ซึ่งสามารถทำได้ผ่านโมดูลที่เรียบง่ายหรือคลาสบริการที่เป็นทางการมากขึ้น ซึ่งมักจะนำไปใช้งานโดยใช้รูปแบบ singleton เพื่อให้แน่ใจว่ามีอินสแตนซ์เดียวตลอดทั้งแอปพลิเคชัน

แนวทางที่ใช้โมดูล

สำหรับแอปพลิเคชันส่วนใหญ่ โมดูลที่เรียบง่ายที่ส่งออกข้อมูลและฟังก์ชันยูทิลิตีบางอย่างก็เพียงพอและสง่างาม

            
// file: src/services/referenceData.ts

// ... (our COUNTRIES constant and derived types from above)

export const getCountries = () => COUNTRIES;

export const getCountryByCode = (code: CountryCode): Country | undefined => {
  // The 'find' method is perfectly type-safe here
  return COUNTRIES.find(country => country.code === code);
};

export const getCountriesByContinent = (continent: Continent): Country[] => {
  return COUNTRIES.filter(country => country.continent === continent);
};

// You can also export the raw data and types if needed
export { COUNTRIES, Country, CountryCode, Continent };

            

              
                Copy
              
            
          

แนวทางนี้สะอาด ทดสอบได้ และใช้ประโยชน์จาก ES modules สำหรับพฤติกรรมคล้าย singleton ตามธรรมชาติ ส่วนใดๆ ของแอปพลิเคชันของคุณสามารถนำเข้าฟังก์ชันเหล่านี้และเข้าถึงข้อมูลอ้างอิงที่สอดคล้องและปลอดภัยทางประเภทได้

การจัดการข้อมูลอ้างอิงที่โหลดแบบอะซิงโครนัส

ในระบบองค์กรจริงจำนวนมาก ข้อมูลอ้างอิงไม่ได้ถูกฮาร์ดโค้ดในส่วนหน้า แต่จะถูกดึงมาจาก API แบ็คเอนด์เพื่อให้แน่ใจว่าข้อมูลนั้นทันสมัยอยู่เสมอในไคลเอนต์ทั้งหมด รูปแบบ TypeScript ของเราต้องรองรับสิ่งนี้

สิ่งสำคัญคือการกำหนดประเภทในฝั่งไคลเอนต์ให้ตรงกับสิ่งที่คาดว่าจะได้รับจาก API จากนั้นเราสามารถใช้ไลบรารีการตรวจสอบความถูกต้องของรันไทม์ เช่น Zod หรือ io-ts เพื่อให้แน่ใจว่าการตอบสนองของ API เป็นไปตามประเภทของเราในรันไทม์ ซึ่งเชื่อมช่องว่างระหว่างธรรมชาติแบบไดนามิกของ API กับโลกแบบคงที่ของ TypeScript

            
import { z } from 'zod';

// 1. Define the schema for a single country using Zod
const CountrySchema = z.object({
  code: z.string().length(2),
  name: z.string(),
  dial: z.string(),
  continent: z.string(),
});

// 2. Define the schema for the API response (an array of countries)
const CountriesApiResponseSchema = z.array(CountrySchema);

// 3. Infer the TypeScript type from the Zod schema
export type Country = z.infer;

// We can still get a code type, but it will be 'string' since we don't know the values ahead of time.
// If the list is small and fixed, you can use z.enum(['US', 'DE', ...]) for more specific types.
export type CountryCode = Country['code'];

// 4. A service to fetch and cache the data
class ReferenceDataService {
  private countries: Country[] | null = null;

  async fetchAndCacheCountries(): Promise {
    if (this.countries) {
      return this.countries;
    }

    const response = await fetch('/api/v1/countries');
    const jsonData = await response.json();

    // Runtime validation!
    const validationResult = CountriesApiResponseSchema.safeParse(jsonData);

    if (!validationResult.success) {
      console.error('Invalid country data from API:', validationResult.error);
      throw new Error('Failed to load reference data.');
    }

    this.countries = validationResult.data;
    return this.countries;
  }
}

export const referenceDataService = new ReferenceDataService();

            

              
                Copy
              
            
          

แนวทางนี้มีความแข็งแกร่งอย่างยิ่ง ให้ความปลอดภัยในเวลาคอมไพล์ผ่านประเภท TypeScript ที่อนุมาน และความปลอดภัยในรันไทม์โดยการตรวจสอบว่าข้อมูลที่มาจากแหล่งภายนอกตรงกับรูปร่างที่คาดไว้ แอปพลิเคชันสามารถเรียก `referenceDataService.fetchAndCacheCountries()` เมื่อเริ่มต้นเพื่อรับรองว่าข้อมูลพร้อมใช้งานเมื่อจำเป็น

การผสานรวมข้อมูลอ้างอิงเข้ากับแอปพลิเคชันของคุณ

ด้วยรากฐานที่มั่นคง การใช้ข้อมูลอ้างอิงที่ปลอดภัยทางประเภทนี้ตลอดทั้งแอปพลิเคชันของคุณจะกลายเป็นเรื่องตรงไปตรงมาและสง่างาม

ในส่วนประกอบ UI (เช่น React)

ลองพิจารณาส่วนประกอบดรอปดาวน์สำหรับการเลือกประเทศ ประเภทที่เราอนุมานไว้ก่อนหน้านี้ทำให้ props ของส่วนประกอบชัดเจนและปลอดภัย

            
import React from 'react';
import { COUNTRIES, CountryCode } from '../services/referenceData';

interface CountrySelectorProps {
  selectedValue: CountryCode | null;
  onChange: (newCode: CountryCode) => void;
}

export const CountrySelector: React.FC = ({ selectedValue, onChange }) => {
  return (
     onChange(e.target.value as CountryCode)}
    >
      Select a country
      {COUNTRIES.map((country) => (
        
          {country.name} ({country.code})
        
      ))}
    
  );
};

            

              
                Copy
              
            
          

ที่นี่ TypeScript รับรองว่า `selectedValue` ต้องเป็น `CountryCode` ที่ถูกต้อง และ callback `onChange` จะได้รับ `CountryCode` ที่ถูกต้องเสมอ

ใน Business Logic และ API Layers

ประเภทของเราป้องกันไม่ให้ข้อมูลที่ไม่ถูกต้องแพร่กระจายผ่านระบบ ฟังก์ชันใดๆ ที่ดำเนินการกับข้อมูลนี้จะได้รับประโยชน์จากความปลอดภัยที่เพิ่มเข้ามา

            
import { OrderStatus } from '../services/referenceData';

interface Order {
  id: string;
  status: OrderStatus;
  items: any[];
}

// This function can only be called with a valid status.
function canCancelOrder(order: Order): boolean {
  // No need to check for typos like 'pendng' or 'Procesing'
  return order.status === 'PENDING' || order.status === 'PROCESSING';
}

const myOrder: Order = { id: 'xyz', status: 'SHIPPED', items: [] };

if (canCancelOrder(myOrder)) {
  // This block is correctly (and safely) not executed.
}

            

              
                Copy
              
            
          

สำหรับการทำให้เป็นสากล (i18n)

ข้อมูลอ้างอิงมักเป็นองค์ประกอบสำคัญของการทำให้เป็นสากล เราสามารถขยายโมเดลข้อมูลของเราเพื่อรวมคีย์การแปลได้

            
export const ORDER_STATUSES = [
  { code: 'PENDING', i18nKey: 'orderStatus.pending' },
  { code: 'PROCESSING', i18nKey: 'orderStatus.processing' },
  { code: 'SHIPPED', i18nKey: 'orderStatus.shipped' },
] as const;

export type OrderStatusCode = typeof ORDER_STATUSES[number]['code'];

            

              
                Copy
              
            
          

ส่วนประกอบ UI สามารถใช้ `i18nKey` เพื่อค้นหาสตริงที่แปลสำหรับภาษาท้องถิ่นปัจจุบันของผู้ใช้ ในขณะที่ตรรกะทางธุรกิจยังคงดำเนินการกับ `code` ที่เสถียรและไม่เปลี่ยนแปลง

แนวทางการกำกับดูแลและบำรุงรักษาที่ดีที่สุด

การนำรูปแบบเหล่านี้ไปใช้งานเป็นจุดเริ่มต้นที่ดี แต่ความสำเร็จในระยะยาวต้องมีการกำกับดูแลที่ดี

• แหล่งข้อมูลเดียวที่เชื่อถือได้ (SSOT): นี่เป็นหลักการที่สำคัญที่สุด ข้อมูลอ้างอิงทั้งหมดควรมาจากแหล่งเดียวและเป็นแหล่งที่เชื่อถือได้เท่านั้น สำหรับแอปพลิเคชันส่วนหน้า นี่อาจเป็นโมดูลหรือบริการเดียว ในองค์กรขนาดใหญ่ สิ่งนี้มักเป็นระบบ MDM เฉพาะที่ข้อมูลถูกเปิดเผยผ่าน API
• ความเป็นเจ้าของที่ชัดเจน: กำหนดทีมหรือบุคคลที่รับผิดชอบในการรักษาความถูกต้องและความสมบูรณ์ของข้อมูลอ้างอิง การเปลี่ยนแปลงควรเป็นไปโดยเจตนาและมีการจัดทำเอกสารอย่างดี
• การกำหนดเวอร์ชัน: เมื่อข้อมูลอ้างอิงถูกโหลดจาก API ให้กำหนดเวอร์ชันของปลายทาง API ของคุณ สิ่งนี้จะป้องกันการเปลี่ยนแปลงที่ส่งผลกระทบในโครงสร้างข้อมูลจากการส่งผลกระทบต่อไคลเอนต์เก่า
• เอกสารประกอบ: ใช้ JSDoc หรือเครื่องมือเอกสารประกอบอื่นๆ เพื่ออธิบายความหมายและการใช้งานของชุดข้อมูลอ้างอิงแต่ละชุด ตัวอย่างเช่น จัดทำเอกสารกฎทางธุรกิจที่อยู่เบื้องหลัง `OrderStatus` แต่ละรายการ
• พิจารณาการสร้างโค้ด: เพื่อการซิงโครไนซ์ขั้นสูงสุดระหว่างแบ็คเอนด์และส่วนหน้า ให้พิจารณาใช้เครื่องมือที่สร้างประเภท TypeScript โดยตรงจากข้อมูลจำเพาะ API แบ็คเอนด์ของคุณ (เช่น OpenAPI/Swagger) สิ่งนี้จะทำให้กระบวนการรักษาประเภทฝั่งไคลเอนต์ให้สอดคล้องกับโครงสร้างข้อมูลของ API เป็นไปโดยอัตโนมัติ

บทสรุป: ยกระดับความสมบูรณ์ของข้อมูลด้วย TypeScript

Master Data Management เป็นระเบียบวินัยที่ขยายออกไปไกลกว่าโค้ด แต่ในฐานะนักพัฒนา เราเป็นผู้เฝ้าประตูสุดท้ายของความสมบูรณ์ของข้อมูลภายในแอปพลิเคชันของเรา โดยการย้ายออกจาก "magic strings" ที่เปราะบางและยอมรับรูปแบบ TypeScript ที่ทันสมัย เราสามารถกำจัดข้อผิดพลาดทั่วไปทั้งหมดได้อย่างมีประสิทธิภาพ

รูปแบบ `as const` รวมกับการอนุพันธ์ประเภท ให้โซลูชันที่แข็งแกร่ง บำรุงรักษาได้ และสง่างามสำหรับการจัดการข้อมูลอ้างอิง สร้างแหล่งข้อมูลเดียวที่เชื่อถือได้ซึ่งรองรับทั้งตรรกะรันไทม์และตัวตรวจสอบประเภทคอมไพล์ไทม์ ทำให้มั่นใจได้ว่าข้อมูลจะไม่คลาดเคลื่อน เมื่อรวมกับบริการแบบรวมศูนย์และการตรวจสอบความถูกต้องของรันไทม์สำหรับข้อมูลภายนอก แนวทางนี้จะสร้างกรอบการทำงานที่ทรงพลังสำหรับการสร้างแอปพลิเคชันระดับองค์กรที่ยืดหยุ่น

ในที่สุด TypeScript เป็นมากกว่าแค่เครื่องมือสำหรับการป้องกันข้อผิดพลาด `null` หรือ `undefined` เป็นภาษาที่ทรงพลังสำหรับการสร้างแบบจำลองข้อมูล และสำหรับการฝังกฎทางธุรกิจโดยตรงในโครงสร้างโค้ดของคุณ โดยการใช้ประโยชน์จากศักยภาพสูงสุดสำหรับการจัดการข้อมูลอ้างอิง คุณจะสร้างผลิตภัณฑ์ซอฟต์แวร์ที่แข็งแกร่ง คาดเดาได้มากขึ้น และเป็นมืออาชีพมากขึ้น